19th  ICCRTS:  Paper  Submission  Cover  Sheet  with  Abstract 

Title  of  Paper:  Network-Centric  Operations  Support:  Lessons  Learned,  Status,  and  Way- Ahead 
Primary  Topic:  Data,  Information,  and  Knowledge  (Topic  3) 

First  Alternate  Topic:  Cyberspace,  Communications,  and  Information  Networks  (Topic  6) 

Second  Alternate  Topic:  Experimentation,  Metrics,  and  Analysis  (Topic  4) 

Authors:  Jayson  Durham,  SSC  Pacific,  San  Diego,  CA  92152-5001 
Riley  Zeller-Townson,  Georgia  Institute  of  Technology,  Atlanta,  GA  30332 
Prof.  Lifford  McLauchlan,  Texas  A&M  University,  Kingsville,  TX  78363 
Prof.  Mehrube  Mehrubeoglu,  Texas  A&M  University,  Corpus  Cristi,  TX,  78412 
Prof.  Richard  Cardenas,  St.  Mary's  University,  San  Antonio,  TX,  78228 
Fernando  Dejesus,  SSC  Pacific,  San  Diego,  CA  92152 
John  McDonnell,  SSC  Pacific,  San  Diego,  CA  92152 

Point  of  Contact:  Jayson  Durham,  SSC  Pacific,  Code  56150,  San  Diego,  CA  92040 
(email)  jayson.durham@navy.mil;  (office)  619-553-2344;  (cell)  619-971-9619 

Abstract 

The  work  reported  herein  focuses  on  how  Model-Based  Systems-of-Systems  Engineering 
(MBSE/SOSE)  methods  and  Enterprise  Architecture  and  Service  Oriented  Architecture  (EA/SOA) 
frameworks  help  to  improve  C2  agility.  Of  particular  interest  is  development  of  highly-reconfigurable 
and  dynamic  frameworks  that  more  effectively  support  distributed  time-sensitive  network-centric 
operations.  From  both  the  research  and  more  operationally  oriented  perspectives,  the  paper  addresses 
lessons  learned  from  previous  and  ongoing  efforts,  reports  on  current  status,  and  discusses  the  way- 
ahead  for  augmenting  MBSE/SOSE  with  model-integration  and  qualification  (I&Q)  capabilities. 

The  progress  reviewed  includes  three  interdependent  areas  of  work.  The  first  focuses  on  business 
services  (i.e.  operations  and  workflow  support)  oriented  MBSE/SOSE  and  associated  EA/SOA  data- 
modeling  improvements.  The  second  area  focuses  on  the  use  of  controlled-vocabularies  within  the 
context  of  business-logic,  business-rule  management  systems  (BRMS),  and  tactical  mission  operations 
support  (e.g.  data-synchronization,  DIL1  condition  exception-handling).  The  last  area  of  work  focuses 
on  use-cases  and  procedures  for  collaborative  experimentation.  Throughout  the  paper,  footnotes  are 
provided  to  assist  readers  with  topics  that  may  be  domain  specific  and  not  more  generally  recognized2. 


1  Disconnected/Disrupted,  Intermittent,  and  Low-bandwidth  (DIL) 

2  Note  to  the  reader:  Technical  references  are  enclosed  in  square  brackets  and  listed  at  the  end  of  the  paper.  The 
superscripted  footnotes  provide  links  that  help  facilitate  an  introductory  understanding  of  concepts  and  topics  that  may 
be  more  common  in  one  technology  domain  but  otherwise  not  familiar  or  as  applicable  to  the  population  at  large. 
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1.  Introduction  and  Executive  Summary 


For  Network  Centric  Warfare  (NCW),  robust  information-sharing  services  are  an  enabler  for  command 
and  control  (C2)  agility.3  In  other  words,  as  stated  within  the  broader  context  of  the  Information 
Sharing  Environment  (ISE)4,  "the  maximum  value  of  information  sharing  occurs  when  the  right 
workers  share  the  right  information  with  the  right  recipients  to  use  at  the  right  time"  [1]. 

As  illustrated  in  figure  1,  agile  NCW  capabilities  (e.g.  agile  C2)  and  supporting  information-sharing 
services  are  based  on  interdependent  standards  and  reference  models  (graphics  from  [2-4]).  For 
example,  figure  1  highlights  the  relationship  between  bottom-line  NCW  Warfighter  operations-support 
services  (i.e.  business-services  models  [graphics  from  4])  versus  the  systems  engineering  support 
models  (e.g.  Joint  C2  Architecture  [graphic  from  2],  DoDAF/DM2  [graphic  from  3]).  From  a  DoD 
Architecture  Framework  (DoDAF/DM2)5  perspective,  this  is  analogous  to  the  DoDAF  dichotomy  of 
systems-versus-operational  views.  In  terms  of  technology  domains  (e.g.  systems  engineering,  business 
management),  figure  1  highlights  that  families  of  models  and  standards  are  similarly  developed  and 
evolve  within  their  respectively  broader  context  (e.g.  engineering  versus  business). 

In  terms  of  a  conceptual  model  of  Information  Dominance  (ID),  figure  2  (from  [5])  highlights  the 
Warfighting  value  of  effective  net-enabled  information  sharing  within  a  model-based  operational 
perspective  (i.e.  operational  view)  of  threat  actors  and  threat  vectors  that  apply  to  Navy  cyberspace 
focus  areas  that  span  a  number  of  operational  domains  (i.e.  cyberspace,  subsurface,  surface/land,  air, 
space).  Thus,  Figure  2  illustrates  that  within  the  Navy,  a  business-services  model  of  NCW  has  evolved 
to  incorporate  cyberspace  operations  that  address  the  emergence  of  cyber  related  threats. 
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Figure  1  Modeling  Domains:  Example  of  Engineering-vs-Business 
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Figure  2  Navy  Cyberspace  Ops:  Desired  End-State 


3  Network-centric  warfare  (http://en.wikipedia.org/wiki/Network-centric_warfare) 

Robustness  (http://en.wikipedia.org/wiki/Robustness_%28computer_science%29) 

Information  sharing  (http://en.wikipedia.org/wiki/Information_sharing) 

Service  (http://en.wikipedia.org/wiki/Service_%28systems_architecture%29) 

Command  and  control  (C2;  http://en.wikipedia.org/wiki/Command_and_control) 

Agility  (http://en.wikipedia.org/wiki/Agility;  http://en.wikipedia.org/wiki/Business_agility) 

4  Information  Sharing  Environment  (ISE;  http://en.wikipedia.org/wiki/Information_Sharing_Environment) 

5  Department  of  Defense  Architecture  Framework  (DODAF;  http://dodcio.defense.gov/dodaf20.aspx; 
http://en.wikipedia.org/wiki/Department_of_Defense_Architecture_Framework);  DoDAF  meta-model  (DM2; 
http://en.wikipedia.Org/wiki/Department_of_Defense_Architecture_Framework#Meta-model) 


As  highlighted  within  figure  1,  figure  2,  and  the  following  sections,  the  cognitive  domain  of  NCW 
operations  and  systems-engineering  support  services  includes  a  broad  range  of  topics/concepts  that 
span  a  number  of  technology  domains  that  apply  to  the  challenge  of  addressing  Warfighting  capability 
gaps  and  new  emerging  threats.  Thus,  due  to  the  breadth  and  depth  of  the  applicable  technology 
domains  that  continue  to  expand  at  unprecedented  rates,  footnotes  are  provided  for  facilitating 
information  sharing  in  terms  of  the  concepts  and  topics  that  apply  to  the  work  discussed  herein.  In  other 
words,  in  addition  to  focusing  on  the  value  of  effective  information-sharing  services,  the  need  for  more 
effective  sharing  of  technical  concepts  is  also  addressed  by  providing  footnotes  throughout  the  paper. 

The  sections  within  the  body  of  the  paper  work  to  address  the  multiplicities  of  domain  models6  that  can 
arise  from  engineering  and  development  activities  that  are  otherwise  isolated  within  their  separate 
application  domains  (e.g.  engineering-versus-business).  Thus,  section  2  discusses  the  families  of 
operational-support  (i.e.  business-services)  models  that  are  the  foundation  and  grounding  of  NCW 
efforts.  More  specifically,  section  2  provides  a  short  review  of  the  NCW  reference  models  that  are  the 
conceptual  foundation  for  agile  C2  and  net-enabled  information-sharing  services.  For  example,  figure  3 
and  figure  4  highlight  what  now  may  be  considered  more  traditional  views  of  NCW,  in  terms  of  the 
bottom-line  operational-support  objectives.  Figure  3  and  figure  4  conceptually  illustrate  how  both  the 
DISA/DoD  and  Navy  NCW/ID  business-services  models  of  figure  1  and  figure  2  are  grounded  within 
such  foundational  NCW  reference  models.  The  goal  of  section  2  is  to  communicate  that  the  conceptual 
reference  models  of  NCW  provide  this  common  grounding  that  continues  to  help  align  and  unite  a 
growing  spectrum  of  disciplines,  technologies,  and  families  of  services  that  must  be  integrated  and 
support  interoperability  across  a  broad  range  of  system-of-systems  (SoS)  boundaries. 

Section  3  focuses  on  highlighting  the  families  of  engineering-support  services  that,  in  principle,  apply 
to  the  engineering  of  NCW  solutions.  In  other  words,  section  3  discusses  the  growing  number  of 
technology  domains  that  support  the  engineering  lifecycle  process.  Within  section  3,  figure  5  illustrates 
that  the  respective  technology  domains  each  have  their  own  families  of  models  and  standards  that  have 
each  evolved  over  time.  The  goal  of  section  3  is  to  communicate  that  NCW  engineering  challenges  go 
beyond  DoDAF/DM2  and  DoD  specific  reference  models  (e.g.  Joint  C2  Architecture). 

To  further  highlight  the  evolution  of  systems-engineering  support  models  and  standards,  section  3 
finishes  up  with  a  discussion  of  the  current  state-of-the-art  in  terms  of  the  lifecycle  and  engineering 
support  processes.  In  other  words,  evolutionary  convergence  of  a  variety  of  model-based  technology- 
development  methodologies  is  also  discussed.  In  particular,  engineering-versus-business  aspects  of 
Model-Based  Systems  Engineering  (MBSE),  System-of-Systems  Engineering  (SOSE),  Enterprise 
Architecture  (EA),  Service  Oriented  Architecture  (SOA),  and  cloud  computing  are  highlighted.7  Thus, 
this  multiplicity  of  applicable  engineering-support  process  models  and  standards  further  highlights  the 
need  for  an  improved  overarching  process  that  more  explicitly  manages  the  conceptual  alignment, 
integration,  and  interoperability  of  reference  models  and  standards. 

Section  4  utilizes  the  Unified  Profile  for  DoDAF/MODAF  (UPDM)  and  associated  Unified  Modeling 
Language  (UML)  standards  as  examples  of  the  naturally  evolving  complexity  of  systems-engineering 
support  models  and  standards.  Within  this  section,  the  goal  is  to  further  communicate  the  need  to  better 

6  Domain  model  (http://en.wikipedia.org/wiki/Domain_model) 

7  MBSE  (http://www.incoseonline.org.uk/Program_Files/Publications/zGuides_9.aspx;  http://www.incose.org) 

System  of  systems  engineering  (SOSE;  http://en.wikipedia.org/wiki/System_of_systems_engineering) 

Enterprise  architecture  (EA;  http://en.wikipedia.org/wiki/Enterprise_architecture) 

Service-oriented  architecture  (SOA;  http://en.wikipedia.org/wiki/Service-oriented_architecture) 

Cloud  computing  (http://en.wikipedia.org/wiki/Cloud_computing) 


utilize  standardized  UML  variants  (i.e.  SysML,  BPMN,  xUML)  for  addressing  the  full  spectrum  of 
software  engineering  (i.e.  UML),  systems  engineering  (i.e.  SysML),  business  process  (i.e.  BPMN),  and 
modeling/simulation  (M&S)  execution  (i.e.  xUML)  lifecycle-support  needs. 

Section  5  highlights  that  MBSE/SOSE  methods  and  best  practices  have  already  facilitated  much 
progress  towards  the  evolution  and  transformation  from  stovepiped  systems  to  families  of  model-based 
net-centric  reusable  and  interoperable  services.  Section  6  continues  with  this  theme  of  progress  by 
reviewing  and  discussing  an  effort  that  works  to  provide  a  new  family  of  EA/SOA  services  that  address 
C2  data-synchronization  needs  and  capability  gaps.  The  goal  of  this  section  is  to  highlight  that  as 
progress  is  being  made  towards  addressing  the  complexities  of  NCW,  the  complexity  and  number  of 
families  of  NCW  information-sharing  services  also  grows. 

Section  7  discusses  a  current  NCW  related  MBSE/SOSE  effort  that  focuses  on  maritime  wireless 
(i.e.  RF)  line-of-sight  (LOS)  communications  and  networking  support.  In  particular,  within  the  context 
of  RF  LOS  link-management,  the  goal  of  the  section  is  to  communicate  technical  and  organizational 
challenges  associated  with  defining,  assessing,  and  validating  mission-driven  measures  of  performance 
and  measures  of  effectiveness  (MOPs/MOEs).  Thus,  this  section  discusses  a  live  example  of  the  need 
for  an  overarching  and  more  unified  model-integration  lifecycle  support  capability  that  enables 
different  programs  of  record  (e.g.  RF  LOS  comms/networking,  unmanned  systems)  to  collaborate 
within  the  requirements,  modeling,  and  conceptual  design  phases  of  the  MBSE/SOSE  lifecycle. 

Section  8  and  and  section  9  further  discuss  the  concept  of  a  more  unified  MBSE/SOSE  lifecycle 
support  process  in  terms  of  existing  resources  and  tools  that  may  be  considered  candidate  components 
within  the  proposed  overarching  lifecycle  support  process.  More  advanced  and  less  mature 
technologies  are  also  discussed  in  terms  of  future  work  and  a  longer  term  roadmap  for  the  way  ahead. 
Finally,  sections  10-12  respectively  provide  a  summary,  acknowledgements,  and  list  of  references. 

2.  Evolving  Models  and  Standards:  NCW  Business-Models  for  Agile  C2  Net-Enabled  Services 

To  further  highlight  the  relative  complexity  and  associated  challenges,  figure  3  and  figure  4  (from  [6]) 
are  provided  as  examples  of  NCW  reference  models  that  focus  on  the  operational  objectives  and 
context  of  agile  C2  and  associated  net-enabled  information  sharing  services.  In  terms  of  the  vision  and 
operational  objectives  of  NCW  and  information  dominance  [7-8],  the  figures  provide  example  views  of 
the  foundational  reference  models  that  currently  drive  DoD  and  maritime  MBSE/SOSE  lifecycle 
processes.  In  addition  to  the  Observe-Orient-Decide-Act  (OODA  Loop)8  pattern  of  decision  making, 
other  reference  models  may  apply  to  a  given  operational  context.  For  example,  Sense-and-Respond  and 
goal-modeling  methods  work  towards  similar  objectives  [9]. 9 

Such  collections  of  decision  making  and  information  dominance  (e.g.  OODA  Loop,  Sense-and- 
Respond)  reference  models  provide  a  conceptual  grounding  that  helps  to  unite  the  broad  spectrum  of 
disciplines,  technologies,  and  families  of  services  that  must  be  integrated  and  support  interoperability 
across  a  range  of  subsystem  and  SoS  boundaries.  In  terms  of  the  desired  end-effects,  the  end-goal  and 
desired  effect  of  MBSE/SOSE  and  EA/SOA/Cloud  lifecycle-support  processes  is  to  facilitate  agile  C2 
capabilities  that  significantly  enhance  decision-making  processes  and  help  to  more  rapidly  and 
seamlessly  bridge  interdependent  physical,  information,  and  cognitive  domains. 


8  OODA  loop  (http://en.wikipedia.org/wiki/OODA_loop) 

9  Sense  and  respond  (http://en.wikipedia.org/wiki/Sense_and_respond) 
Goal  modeling  (http://en.wikipedia.org/wiki/Goal_modeling) 


From  a  more  traditional  systems  engineering  perspective,  this  focus  on  end-user  performance,  versus 
systems  and  systems  services,  can  be  a  particularly  challenging  task.  From  a  more  business  process  and 
workflow  management  perspective,  end-user  performance  is  typically  tied  to  a  return  on  investment 
(ROI)10.  In  other  words,  from  a  business  perspective,  the  focus  is  on  the  bottom-line  effectiveness  of 
the  services  performed  for  the  resources  invested,  versus  the  enabling  technologies.  Thus,  further 
highlighting  the  multi-disciplinary  (e.g.  business  versus  engineering)  challenges  associated  with 
developing  more  unified  end-to-end  enterprise  engineering  oriented  product  lifecycle  management 
(PLM)  processes.* 11  Ideally,  such  a  unified  approach  helps  to  better  capture  MOPs/MOEs  in  terms  of  the 
bottom-line  improvements  in  ROI  and  end-user  performance  (e.g.  decision  making). 
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Figure  3  Boyd  OODA-Loop  Model 


Figure  4  Net-Enabled  Capability  and  Decision  Cycles 


3.  Evolving  Models  and  Standards:  NCW  Engineering-Support  Reference  Models  and  Standards 


Figure  5  highlights  that  within  NCW  related  technology  domains,  there  are  a  range  of  standardized 
families-of-models  that  each  have  their  own  family  histories  [10],  in  terms  of  their  own  evolution  over 
time  (figure  diagrams  from  [11-14]).  Thus,  the  ongoing  and  growing  need  to  more  explicitly  manage 
such  technical  standards  and  reference  models  within  the  overall  lifecycle  process.  In  other  words,  the 
figure  highlights  that  NCW  applications  are  inherently  multi-disciplinary  and  employ  interdependent 
technology  domains,  such  as  EA/SOA,  systems  engineering,  software  engineering,  information  and 
communications  technology  (ICT),  complex  systems,  and  computational  modeling/simulation.12 


Figure  6  (from  [15])  is  an  example  of  a  Model-Based  Systems  Integration  (MBSI)  systems 
development  process,  wherein  model  integration  and  systems  integration  are  both  incorporated  within 
an  overarching  MBSE/SOSE  process.  As  highlighted  within  the  figure,  separately  designed  subsystems 
are  brought  within  a  collaborative  model-integration  and  qualification  (I&Q)  resource  that  facilitates  a 
more  unified  model-integration,  qualification,  and  build  capability.  Within  [15]  and  this  paper,  the  term 
qualification  includes  verification,  validation,  and  acceptance.  In  principle,  this  focus  on  I&Q  improves 
development  of  the  requirements  and  specifications  that  drive  subsequent  phases  of  the  the  SE  process. 


10  Return  on  investment  (ROI;  http://en.wikipedia.org/wiki/Return_on_investment) 

11  Enterprise  engineering  (E2;  http://en.wikipedia.org/wiki/Enterprise_engineering) 

Product  lifecycle  management  (PLM;  http://en.wikipedia.org/wiki/Product_lifecycle_management) 

12  Systems  engineering  (SE;  http://en.wikipedia.org/wiki/Systems_engineering) 

Software  engineering  (http://en.wikipedia.org/wiki/Software_engineering) 

Information  and  communications  technology  (ICT; 

http://en.wikipedia.org/wiki/Information_and_communications_technology) 

Complex  systems  (http://en.wikipedia.org/wiki/Complex_systems) 

Computer  simulation  (http://en.wikipedia.org/wiki/Computer_simulation) 


As  will  be  discussed  in  more  detail  in  later  sections,  MBSI  approaches  are  critical  for  ensuring  that 
performance  measurements13,  such  as  mission-thread  driven  measures-of-performance  and  measures- 
of-effectiveness  (MOPs/MOEs),  are  correctly  identified,  assessed,  and  validated.  For  example,  NCW 
C4ISR  CONOPS  that  are  expected  to  rely  on  unmanned  systems  (UxS),  typically  have  time-critical 
information  exchange14  requirements  (IERs)  that  must  be  anticipated  and  met  during  mission  execution. 


Software  Engineering  (e^g  OMG/UML) 


Enterprise  Architecture  (EA)  &  Information 
and  Communications  Technology  (ICT) 


Complex  Systems  &  Computational  Modeling 


System  Design  Model  Integration  Build  System  Integration 


Figure  5  Example  Timelines  of  Model-Based  Standards  Figure  6  Example  of  Model-Based  Systems  Integration  (MBSI) 


Within  such  mission  execution  contexts,  UxS  subsystems  may  be  expected  to  operate  in  contested  areas 
during  DIL  (i.e.  disconnected/disrupted,  intermittent,  low-bandwidth)  conditions,  where  tactical 
communications  and  networking  support  services  may  be  severely  degraded.  In  other  words,  for 
tactical  afloat  and  forward  operating  areas,  ICT  oriented  RF  communications  and  networking  support 
services  (e.g.  tactical  RF  comms/networking  information-sharing  services)  are  expected  to  be  robust  to 
DIL  conditions  and  gracefully  degrade  with  respect  the  baseline  mission-thread  requirements 
(i.e.  MOPs/MOEs).  Such  context  dependent  (e.g.  mission-thread  execution)  RF  comms/networking 
quality  of  service  (QoS)  requirements  necessitate  the  development  of  MBSI  types  of  engineering 
processes  where  subsystem  level  IERs  can  be  assessed  in  terms  of  anticipated  mission-thread 
MOPs/MOEs  (e.g.  operating  under  DIL  conditions).  Associated  QoS  requirements  include 
threshold/objective  information-exchange  latencies,  as  well  as,  workflow-level  exception-handling 
when  QoS  requirements  are  at  risk.  Thus,  capability  gaps  may  be  more  readily  identified  and  addressed 
within  the  requirements  engineering  and  early  systems-design  stages  of  the  MBSE/SOSE  lifecycle. 

For  MBSE/SOSE  requirements  management  and  engineering  activities  (i.e.  tracing  and  assessment), 
the  payoff  for  a  collaborative  model  integration  resource  is  the  ability  to  better  analyze  and  assess 
baseline  vignettes  (e.g.  mission-threads)  and  possible  excursions  (e.g.  operating  under  various  DIL 
conditions).15  This  enables  the  analysis  and  assessment  of  a  variety  of  possible  conditions  that  can  be 
addressed  at  the  requirements  level  (e.g.  MOP/MOE)  and  architectural  design  level.  This  type  of 
collaborative  requirements  and  system  design  capability  helps  to  facilitate  the  development  of  the  most 
effective  and  desired  agile  support  services  (e.g.  RF  comms/networking),  as  needed  for  net-centric 
tactical  C4ISR  operations  (e.g.  time  sensitive  targeting16). 


13  Performance  measurement  (http://en.wikipedia.org/wiki/Performance_measurement) 

14  Information  exchange  (http://en.wikipedia.org/wiki/Information_exchange; 
http://en.wikipedia.org/wiki/Information_transmission;  http://en.wikipedia.org/wiki/Communication_channel) 

15  Requirements  management  (RM;  http://en.wikipedia.org/wiki/Requirements_management) 

Requirements  engineering  (RE;  http://en.wikipedia.org/wiki/Requirements_engineering) 

16  JP  3-60  (cfr.org/content/publications/attachments/Joint_Chiefs_of_Staff-Joint_Targeting_31_January_2013.pdf) 


4.  Evolving  Complexity  of  Models  and  Standards:  Unified  Modeling  Language  (UML)  Example 


As  highlighted  within  the  example  time  lines  of  figure  5,  MBSE/SOSE  related  technology  domains 
continue  to  mature,  adapt,  and  evolve  over  time.  Within  the  software  engineering  domain,  for  example, 
the  Object  Management  Group  (OMG)  Unified  Modeling  Language  (UML),  which  originated  from  the 
unification  of  competing  object-oriented  (OO)  analysis  and  design  methodologies,  has  continued  to 
mature  and  develop  to  the  present  date.17  With  the  introduction  and  subsequent  adoption  of  the  Unified 
Profile  for  DoDAF/MODAF  (UPDM)18,  UML  has  become  a  more  common  standard  for  representing 
DoDAF  architecture  products.  This  has  also  enabled  the  incorporation  of  the  OMG  model-driven 
architecture  (MDA)  and  associated  model-driven  engineering  (MDE)  standards  for  facilitating  and 
augmenting  MBSE/SOSE  processes  and  best-practices.19 

Within  the  context  of  UML,  the  relatively  recent  introductions  of  the  OMG  Systems  Modeling 
Language  (SysML)  standard  and  OMG  Business  Process  Model  and  Notation  (BPMN)  standard,  have 
established  separate  interdependent  visually-intensive  modeling  language  variants  wherein  each  serves 
domains  (i.e.  areas  of  concern)  that  respectively  focus  on  systems  engineering  (SE)  and  business 
process  management  (BPM),  versus  OO  software  development.20  Within  the  context  of  BPM  and 
associated  workflow21  services,  BPMN  is  a  business  process  oriented  standard  that  has  a  longstanding 
relationship  within  the  more  business  oriented  EA/SOA  community.  While  both  SysML  and  BPMN 
address  multi-disciplinary  engineering  support  needs,  this  nonetheless  demonstrates  the  added 
complexities  for  developing  and  sustaining  net-centric  information  sharing  services. 

The  SysML  standard  provides  an  added  example  of  the  challenges  associated  with  navigating  across 
the  variants  of  inter-related  reference  models  and  standards.  As  an  extension  of  a  subset  of  UML, 
SysML  has  been  created  due  to  the  need  to  provide  systems  engineering  (SE)  improvements  to  the 
historically  software-centric  UML  standard.  For  example,  the  definition  of  SysML  requirements  and 
parametric  diagram  types  provides  enhanced  requirements  engineering,  performance  analysis,  and 
quantitative  analysis  support.  Such  SE  oriented  enhancements  enable  SysML  to  model  a  wide  range  of 
systems,  which  may  include  hardware,  software,  information,  processes,  personnel,  and  facilities.  From 
a  SE  standards  perspective,  SysML  extensions  enable  UML's  architectural  design  and  modeling 
capabilities  to  be  better  aligned  with  standardized  methodologies  for  developing  software-intensive 
systems  (e.g.  ISO/IEC/IEEE  4201022  [16]).  Thus,  the  relatively  recent  emergence  of  such  SE  oriented 
variants  of  historically  software-only  standards  (e.g.  UML),  illustrates  the  current  multi-disciplinary 
MBSE/SOSE  requirement  for  knowing  which  variant  is  most  appropriate  within  the  respective  process 
development  context  (e.g.  software  development,  systems  engineering,  business  process  management). 
Business  process  and  workflow  management  oriented  variants  (e.g.  BPMN)  similarly  introduce 
challenges  within  the  end-user  operations-support  context.  Model-level  interoperability  across  the 
respective  variants  of  UML  based  standards  (e.g.  SysML,  BPMN)  is  an  additional  challenge. 

17  Unified  Modeling  Language  (UML;  http://en.wikipedia.org/wiki/Unified_Modeling_Language) 

Object-oriented  analysis  and  design  (OOAD;  http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design) 

18  UPDM  (http://en.wikipedia.org/wiki/UPDM) 

19  Model-driven  architecture  (MDA;  http://en.wikipedia.org/wiki/Model-driven_architecture) 

Model-driven  engineering  (MDE;  http://en.wikipedia.org/wiki/Model-driven_engineering) 

Best  practice  (http://en.wikipedia.org/wiki/Best_practice) 

20  Systems  Modeling  Language  (SysML;  http://en.wikipedia.org/wiki/Systems_Modeling_Language) 

Business  Process  Model  and  Notation  (BPMN;  http://en.wikipedia.org/wiki/Business_Process_Model_and_Notation) 
Business  process  management  (BPM;  http://en.wikipedia.org/wiki/Business_process_management) 

21  Workflow  (http://en.wikipedia.org/wiki/Workflow) 

22  ISO/IEC  42010  (http://en.wikipedia.org/wiki/ISO/IEC_42010) 


For  MBSE/SOSE  lifecycle  support,  another  recently  introduced  variant  of  UML  is  of  interest. 
Executable  UML  (xUML)23  "combines  a  subset  of  the  UML  (Unified  Modeling  Language)  graphical 
notation  with  executable  semantics  and  timing  rules"  [17].  As  noted  within  a  recent  survey  of  modeling 
and  simulation  of  systems-of-systems  [18],  recently  introduced  enhancements  to  the  DoDAF 
specification  [19-20]  contain  modeling  and  simulation  (M&S)  as  a  tool  for  developing  “executable 
architecture”  and  providing  detailed  DoDAF  to  discrete-event  system  specification  (DEVS)24  mapping 
in  simulation  and  feasibility  analysis.  The  result  is  an  improved  system  lifecycle  development  that 
contains  model-continuity  based  design  and  testing  in  an  integral  form.  Other  references  further  discuss 
the  value  of  methods  and  tools  that  support  "executable  architecture"  capabilities  (e.g.  xUML,  DEVS) 
[21-22].  In  the  context  of  the  work  described  herein,  the  key  point  is  that  the  value  added  by  such  M&S 
oriented  variants  of  UML  (and  consequently  DoDAF),  further  complicates  the  MBSE/SOSE  process. 

Separate  from  UPDM  and  UML,  the  DoD  Architecture  Framework  (DoDAF)  emerged  from  the 
original  C4ISR  Architecture  Framework,  which  separately  emerged  from  the  context  of  the  Zachman 
and  NIST  EA  models  and  Enterprise  Resource  Planning  (ERP)  (circa  1990s).25  Thus,  the  evolution  of 
DoDAF  has  primarily  been  in  conjunction  with  the  congressionally  mandated  Clinger-Cohen  Act  and 
associated  federal  enterprise  architecture  (FEA).26  DoDAF  2.0  is  an  upgrade  of  DoDAF  (circa  2009) 
that  addresses  the  need  to  further  align  with  the  evolution  and  maturity  of  EA/SOA  methodologies  and 
best-practices.  This  is  another  example  of  the  variety  of  standards  legacies  and  associated  variants  that 
are  commonly  encountered  within  particular  technology  domains.  For  multi-disciplinary  engineering 
activities  (e.g.  MBSE/SOSE),  this  type  of  standards  and  reference  model  variability  is  compounded  by 
the  potential  lack  of  familiarity  and  inability  to  cross  disciplinary  boundaries.  Thus,  the  need  for  more 
explicit  model  management  and  integration  support  for  the  overall  lifecycle  process  (e.g.  MBSI). 

5.  The  Evolving  Complexity  of  MBSE/SOSE:  Examples  of  Progress  to  Date 

Within  the  last  decade,  there  have  been  a  number  of  efforts  that  address  the  need  to  deconstruct  and 
transform  monolithic  stovepiped  legacy  systems  into  families  of  reusable  and  inoperable  services.  The 
progress  to  date  with  such  efforts  helps  to  establish  a  foundation  for  developing  model-based  I&Q 
approaches  within  lifecycle  support  processes  and  best-practices.  Figure  7  illustrates  ongoing  efforts  to 
evolve  and  transform  tightly-coupled  monolithic  legacy  systems  into  families  of  net-enable  services 
(diagrams  from  [23,  4]).  As  previously  highlighted  within  the  context  of  a  proposed  Enterprise 
Engineering  Reference  Model  (E2RM)  [24],  figure  8  (diagrams  from  [24])  illustrates  the  goals  and 
objectives  of  an  ongoing  PEO-C4I  Enterprise  Engineering  and  Certification  (E2C)  support  activity  that 
shares  this  vision  of  maximizing  reuse  and  interoperability  [25].  The  focus  of  the  E2C  has  been 
towards  systems  interoperability  assessment  and  validation  processes  for  mitigating  potential 
interoperability  risks  that  cross  program  of  record  (POR)  boundaries.  Thus,  MBSE/SOSE  and 
EA/SOA/Cloud  methodologies,  reference  models,  best-practices,  and  standards  are  fast  approaching 
the  ability  to  develop  a  more  cohesive  and  rigorously  managed  end-to-end  lifecycle-support  process. 


23  Executable  UML  (http://en.wikipedia.org/wiki/Executable_UML) 

24  DEVS  (http://en.wikipedia.org/wiki/DEVS) 

25  Sowell,  P.,  "The  C4ISR  Architecture  Framework:  History,  Status,  and  Plans  for  Evolution,"  2006. 
(http://www.dtic.mil/dtic/tr/fulltext/u2/a456187.pdf) 

Enterprise  architecture  framework  (http://en.wikipedia.Org/wiki/Enterprise_Architecture_framework#History) 
Enterprise  resource  planning  (http://en.wikipedia.org/wiki/Enterprise_resource_planning) 

26  Clinger-Cohen  Act  (http://en.wikipedia.org/wiki/Clinger-Cohen_Act) 

Federal  enterprise  architecture  (FEA;  http://en.wikipedia.org/wiki/Federal_enterprise_architecture) 


For  agile  C2,  this  type  of  tactical  C4ISR  operations  support  is  critical  for  the  way  ahead.  This  is 
especially  true  due  to  emerging  non-kinetic  threats,  such  as  cyber  and  electronic  warfare.  With  the 
emergence  and  proliferation  of  a  growing  range  of  standards  that  apply  to  a  growing  variety  of  different 
inter-dependent  technology  domains,  there  is  an  additional  need  for  more  explicitly  supporting  the 
integration  and  model-level  management  of  different  families  of  net-centric  EA/SOA/Cloud  services. 


In  particular,  for  supporting  afloat/forward  tactical  C4ISR  IERs  (e.g.  UxS  information-exchanges),  the 
assessment  and  derivation  of  mission-level  requirements  (e.g.  MOPs/MOEs)  requires  collaborative 
model-based  requirements  engineering  (e.g.  analysis,  assessment,  validation)  and  systems  design 
activities.  Thus,  the  value  and  payoff  for  further  developing  and  utilizing  MBSI  types  of  approaches. 


•egacv  Prograrr 
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Figure  7  Evolution  from  Systems  to  Services 


Figure  8  Enterprise  Engineering  (E2)  MBSE  Objectives 


6.  Evolving  Complexity  of  Models  and  Standards:  Example  from  Previous  Work 

As  highlighted  and  discussed  in  the  previous  sections,  agile  C2  capabilities  are  critically  dependent 
upon  the  synchronization  of  dataflows  that  support  the  IERs  of  the  respective  net-centric  operational 
workflow  (e.g.  mission-thread  execution).  From  a  EA/SOA  perspective,  a  generic  set  of  interfaces  can 
be  defined  for  establishing  a  functional  taxonomy  of  the  types  of  services  that  are  typically  associated 
with  data-synchronization27  needs  and  requirements.  Most  generally,  much  of  the  functionality 
associated  with  data-synchronization  typically  relates  to  distributed  computing  requirements,  as  they 
relate  to  distributed  concurrency  control  and  distributed  transaction  management.28 

Figure  9  and  figure  10  are  from  recently  reported  progress  towards  establishing  an  initial  family  of  C2 
data-synchronization  services  (C2SS)  [26].  The  goal  of  the  C2SS  effort  can  be  viewed  as  including  a 
refactoring  of  Quality  of  Service  (QoS)  and  non-functional  requirements  that  need  to  be  addressed  as 
distributed  computing  challenges  that  span  the  respective  layers  of  an  EA/SOA  services  stack  (e.g. 
presentation  layer,  services  layer,  business  layer,  data  layer).29  This  type  of  conceptual  and  logical 
restructuring  is  another  example  of  the  evolution  towards  a  services-oriented  design  perspective. 

Conceptually,  from  a  NCW  "cognitive  domain"  and  business-services  perspective,  C2SS  can  be  viewed 

27  Data  synchronization  (http://en.wikipedia.org/wiki/Data_synchronization) 

28  Distributed  computing  (http://en.wikipedia.org/wiki/Distributed_computing) 

Distributed  concurrency  control  (http://en.wikipedia.org/wiki/Distributed_concurrency_control) 

Distributed  transaction  (http ://en. wikipedia.org/wiki/Distributed_transaction) 

29  Quality  of  service  (http://en.wikipedia.org/wiki/Quality_of_service) 

Non-functional  requirement  (http://en.wikipedia.org/wiki/Non-functional_requirement) 

Multilayered  architecture  (http://en.wikipedia.org/wiki/Multilayered_architecture) 


as  an  encapsulation  of  services  within  a  logically  defined  data-layer.  Thus,  figure  9  (from  [26]) 
illustrates  this  new  family  of  services.  In  terms  of  the  deployment  of  C2SS  service  components,  a 
variety  of  techniques  can  be  utilized,  such  as  dependency  injection  patterns,  to  provide  specific 
information-sharing  support  services  within  specific  dataflows  (e.g.  IP  packet  flow).30  In  other  words, 
C2SS  functions  are  intended  to  provide  enhanced  ongoing  support  for  C2  mission-level  IERs  and 
associated  information-exchange  MOPs/MOEs.  As  highlighted  in  figure  10  (from  [26]),  C2SS 
functionality  can  be  implemented  using  sets  of  adapters,  for  which  application  programming  interfaces 
(APIs)  and  service  descriptions  (e.g.  IDL,  RSDL,  OSID)  can  be  defined  and  supported.31  Through  the 
development  of  such  EA/SOA  functionality,  C2SS  services  perform  data-synchronization  operations 
within  the  data  paths  that  logically  connect  information  sources  (e.g.  data  streams,  data  stores)  and  end- 
user  workflow-support  applications  (e.g.  C4ISR  apps  and  user-interface  widgets).32 


Figure  10  lists  an  example  of  "eventual  consistency"33  at  the  top  of  the  partial  list  of  candidate  C2SS 
functions.  Generically,  eventual  consistency  "informally  guarantees  that,  if  no  new  updates  are  made  to 
a  given  data  item,  eventually  all  accesses  to  that  item  will  return  the  last  updated  value"  (quote  from 
reference  in  footnote  59)  This  type  of  C2SS  function  enables  resynchronization  after  communication 
channels34  are  disconnected  or  intermittently  interrupted.  In  this  case,  for  geo-replicated  instances  of 
shared  data  elements,  the  values  of  the  replicated  data  elements  eventually  become  consistent.  Thus,  the 
term  "eventual  consistency."  Within  the  context  of  document  management,  distributed  revision 
control35  is  another  example  and  way  of  describing  this  type  of  data-synchronization  functionality. 

From  a  C2SS  perspective,  the  goal  is  to  decouple  implementation  details  from  baseline  platform- 
independent  service  descriptions.  Thus,  service  instances  are  not  bound  to  specific  implementations. 
Furthermore,  instances  of  such  services  can  be  tailored  to  address  context-specific  IER  needs. 


Figure  9  C2  Data-Synchronization  Services  (C2SS) 


Figure  10  Dependency  Injection  and  Adapter  Patterns  Example 


30  Dependency  injection  (http://en.wikipedia.org/wiki/Dependency_injection) 

Traffic  flow  (computer  networking)  (http://en.wikipedia.org/wiki/Traffic_flow_%28computer_networking%29) 

31  Adapter  pattern  (http://en.wikipedia.org/wiki/Adapter_pattern) 
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34  Channel  (communications)  (http://en.wikipedia.org/wiki/Channel_%28communications%29) 
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The  initial  work  highlighted  in  figure  9  and  figure  10  has  been  carried  forward  and  adapted  to  more 
specifically  address  a  need  for  developing  a  MBSI  type  of  process  for  I&Q  of  mission-based 
MOP/MOE  related  requirements.  More  specifically,  the  focus  of  current  efforts  (i.e.  FY 14)  addresses 
data-synchronization  challenges  for  wireless  (e.g.  RF)  line  of  sight  (LOS)  ad-hoc  comms/networking 
support  for  afloat/forward  area  tactical  C4ISR  operations.  An  example  of  a  key  issue  for  this  specific 
use-case,  relates  to  the  use  of  Internet  Protocol  (IP,  IPv6)  based  information-exchange  standards  (e.g. 
TCP,  UDP)  for  satisfying  mission-task  IERs.36  Within  this  context  of  RF  LOS  comms/networking  IP- 
based  information-sharing  support  services,  the  challenge  is  to  determine  the  relative  timing 
requirements  for  reshaping  the  physical  RF  LOS  network  topology,  as  a  function  of  the  mission-based 
IP-based  data-exchange  MOPs/MOEs  (e.g.  UxS  IERs  during  DIL  conditions). 

7.  Need  for  Requirements  and  Model-Integration  Support:  Example  from  Current  Work 

For  maritime  blue-ocean  and  ship-to-shore  operations,  ad-hoc  wireless  (i.e.  RF)  networking  presents  a 
number  of  challenges.  Ideally,  for  RF  LOS  ad-hoc  networks,  the  dynamic  shaping  of  the  physical 
network  topology37  (i.e.  allocation  and  deallocation  of  links)  should  be  coordinated  with  the  logical 
connections  and  associated  dataflows  supported  by  the  respective  RF  LOS  links  and  infrastructure 
components  (e.g.  routers,  switches).  Furthermore,  as  discussed  earlier,  the  operational  end-user 
workflow  support  requirements  and  QoS  objectives  should  drive  the  link  management  process. 

In  addition  to  a  number  of  open  technical  challenges  associated  with  developing  this  type  of  mission- 
driven  RF  comms/networking  support  capability,  there  is  also  an  organizational  need  for 
collaboratively  defining,  assessing,  and  validating  MOPs/MOEs  that  quantify  the  range  of  associated 
data-synchronization  requirements  (e.g.  information-exchange  latencies).  In  other  words,  a  MBSI  type 
of  process  is  needed  for  developing  best-practices  (e.g.  SOPs38)  that  help  to  establish  mission- 
dependent  objective  and  threshold  values  that  drive  link-management  policies  and  requirements. 

Figure  11  and  figure  12  are  diagrams  that  were  created  to  illustrate  this  RF  LOS  comms/networking 
link-management  challenge.  As  seen  in  figure  11,  the  EA/SOA  oriented  services  stack  parallels  the 
comms/networking  oriented  OSI  model  (i.e.  protocol  stack).39  Note  that  due  to  the  focus  on  "data  in 
motion"  and  "data  in  use",  a  EA/SOA  data-layer  (data-services  layer)  for  managing  "data  at  rest"  (e.g. 
data  persistence)  is  assumed  but  not  shown.40  In  terms  of  mission  performance  (i.e.  operations 
workflow  support)  and  associated  mission-dependent  information-exchange  requirements  (e.g. 
MOPs/MOEs),  the  RF  LOS  link-manager  is  a  number  of  layers  removed  from  the  end-user.  In  other 
words,  there  is  a  need  for  logical-layer  and  application-layer  support  services  that  enable  and  augment 
misson-driven  link-management  services. 
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38  Standard  operating  procedure  (SOP;  http://en.wikipedia.org/wiki/Standard_operating_procedure) 

39  OSI  model  (http://en.wikipedia.org/wiki/OSI_model) 
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Persistence  (computer  science)  (http://en.wikipedia.org/wiki/Persistence_%28computer_science%29);  Persistent  data 
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As  highlighted  within  the  more  detailed  block  diagram  (figure  12),  there  are  a  number  of  logical-layer 
services  that  are  needed  for  facilitating  mission-driven  connectivity  management  and  logical  IP-based 
dataflow  management.  Thus,  within  these  middleware  layers,  the  respective  application-layer  tasks, 
such  as  Warfighter  tasks  (e.g.  C2,  ISR)  and  mission-support  tasks  (e.g.  data-synchronization,  entity 
management),  need  to  work  collaboratively  with  physical-layer  oriented  RF  LOS  link-management 
tasks  to  established  objective  and  threshold  values  for  link-management  MOPs/MOEs  that  can  most 
effectively  support  Warfighter  policies  and  needs  (i.e.  QoS,  IERs). 


Physical 

Layer 

RF  LOS  Link 
manager,  Links 


Logical 

Layer 

Connectivity 
manager,  RF 
LOS  relays 


Scheduler 


Gateway 


Relay 


1:  Physical  2:  Link  3:  Network  5:  Session  6:  Presentation 

4:  Transport  7:  Application 


Application 

Layer 

Relays,  vehicles, 
user  interface 


User  Layer 

Operations, 

Workflow 


“Layer  8” 

(Individual,  End-User) 


Figure  11  EA/SOA  Layering  of  Link-Management  Services 
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Figure  12  Systems  View  ofRF  LOS  Link-Management 


Figure  13  illustrates  how  existing  standards  can  be  leveraged  for  developing  an  initial  RF  LOS  link- 
management  capability.  The  logical-layer  services  highlighted  within  figure  12  are  encapsulated  into  a 
connectivity-manager  that  functionally  decouples  the  physical-layer  services  (e.g.  link-manager)  from 
the  various  application-layer  entities  (stakeholders)  that  may  concurrently  participate  within  a  specific 
commonly-understood  task  (e.g.  element  of  the  UJTL41  taxonomy).  Using  standardized  sequencing 
diagrams  (e.g.  UML  sequence  diagram42),  the  operational  and  technical  details  for  how  processes  need 
to  operate  with  one  another  and  in  what  order,  can  be  collaboratively  determined  and  documented. 

Families  of  possible  variations  of  event  scenarios  can  be  generated,  relative  to  a  given  baseline  use- 
case.  Furthermore,  using  standardized  information-exchange  taxonomies  (i.e.  controlled  vocabularies), 
such  as  the  National  Information  Exchange  Model  (NIEM),  unambiguous  information  sharing,  relative 
to  a  specific  mission-task  context,  is  possible  for  a  broad  range  of  possible  ad-hoc  virtual-teaming 
situations.43  Thus,  through  the  utilization  of  established  standards  (e.g.  UML  sequence  diagrams, 

UJTLs,  NIEM),  mission-task  specific  information-exchange  MOPs/MOEs  can  be  determined,  assessed, 
and  ultimately  validated  by  collaborative  experiments  and  operational  exercises. 

Figure  14  is  a  dataflow  diagram  for  an  initial  data-collection  experiment  that  works  to  document  the 
variability  of  information-exchange  events  that  represent  the  types  of  IERs  that  are  associated  with  UxS 
tactical  C4ISR  scenarios  (i.e.  CONOPS).  Thus,  this  type  of  standardized  experimentation  process 
augments  and  enhances  the  early  MBSE/SOSE  lifecycle  processes  that  support  model-integration  and 
executable-architecture44  capabilities.  The  payoff  is  collaborative  mission-thread  analysis,  assessment, 
and  validation  within  the  early  phases  of  the  respective  MBSE/SOSE  lifecycle.  In  other  words,  the 
experimentally  derived  information-exchange  statistics  facilitate  higher  fidelity  collaboration 


41  Universal  Joint  Task  List  (UJTL;  http://en.wikipedia.org/wiki/UJTL) 

42  Sequence  diagram  (http://en.wikipedia.org/wiki/Sequence_diagram) 

43  Controlled  vocabulary  (http://en.wikipedia.org/wiki/Controlled_vocabulary) 

National  Information  Exchange  Model  (NIEM;  http://en.wikipedia.org/wiki/National_Information_Exchange_Model) 

44  Executable  architecture  (http://en.wikipedia.org/wiki/Executable_architecture) 


opportunities  that  ensure  correct  system  designs  are  in  place  before  the  respective  subsystems  are  built 
and  deployed  to  an  operational  EA/SOA/Cloud  framework  for  interoperability  testing  and  validation. 
Most  importantly,  much  needed  MOP/MOE  estimates  can  be  generated  within  the  respective  design 
phases  of  the  inter-dependent  subystems  (e.g.  RF  LOS  link  management,  UxS  mission-area 
applications).  This  type  of  data-collection  experiment  is  scheduled  for  the  Trident  Warrior  2014 
(TW14)  experiment.  These  initial  IER  related  statistics  are  intended  to  provide  a  working  baseline  for 
collaborative  assessment  and  validation  of  mission-driven  link-management  MOPs/MOEs. 
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Figure  13  Example  Seq.  Diagram  Using  Task  &  Data  Standards  Figure  14  Example  Data-Collection  Exp.  for  IER  Analysis 


From  a  standardized  task  management  (e.g.  UJTL/UNTL  driven  workflow)  perspective,  the  IER  related 
information  collected  at  TW14  (e.g.  latency  distributions  for  prototypical  information-exchange  events) 
helps  to  identify  and  assess  the  parameters  and  respective  objective/threshold  values  that  determine  the 
risk  status  for  a  specific  mission  task  (e.g.  UJTL/UNTL)  or  collection  of  tasks  (e.g.  METL45).  This  type 
of  task-execution  information  is  critical  for  the  business-logic  aspects  of  battle  management,  and 
recently  developed  battle  management  language  capabilities  [27-28].  For  example,  risks  due  to 
information-exchange  delays  (e.g.  DIL  conditions),  can  be  represented  and  managed  at  the  stakeholder 
workflow-level  of  mission-support  services.  Within  the  commercial  sector,  business-rules  approaches 
are  another  example  of  this  type  of  management  of  dynamic  work  environments.  Business  rules  are 
especially  useful  for  establishing  and  managing  policies  for  how  to  manage  situations  that  are  outside 
normal  (i.e.  baseline)  operating  conditions.  From  a  systems  design  perspective,  this  type  of  information 
is  useful  for  assertion  oriented  methodologies  (e.g.  exception  handling,  design-by-contract)  that  utilize 
conditional-execution  specifications  (e.g.  precondition,  postcondition,  invariant).46 

The  collaborative  development  of  link-management  MOPs/MOEs  enables  the  development  of  the 
logical  content  (e.g.  QoS  policies,  service  assurance  requirements,  business-rules)  needed  for 
COTS/GOTS  business-rule  management  system  (BRMS)  approaches  to  workflow  support.47  This  is  of 


45  Joint  Mission  Essential  Task  List  (JMETL)  Development  Handbook  (www.dtic.mil/dtic/tr/fulltext/u2/a331999.pdf) 
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particular  interest  due  to  the  availability  of  standards  (e.g.  OMG  SBVR),  methodologies  (e.g.  business- 
rule  approach),  and  BRMS  resources  (e.g.  business-rule  engines,  inferencing  engines,  JBoss  Drools).48 
The  payoff  for  utilizing  BRMS  resources  is  the  potential  flexibility  in  dynamically  managing  context- 
dependent  business  logic49.  Ideally,  for  managing  operational  workflow,  a  BRMS  supports  the  dynamic 
business-logic  aspects  of  tactical  operations  support  (e.g.  data-synchronization,  DIL-condition  related 
workflow-level  exception-handling) . 

With  the  growing  availability  and  use  of  controlled  vocabularies  and  common  terminologies  (e.g. 
UJTL/UNTL,  NIEM),  BRMS  approaches  provide  opportunities  to  enable  semantic  interoperability50 
within  both  the  MBSE/SOSE  and  end-users'  information  and  cognitive  domains.  In  particular, 
controlled-vocabulary  and  content  management  services  can  enable  responsive  lexicon-support  for 
tactical  mission  execution  support  [29-31].  Thus,  further  enhancing  C2  agility. 

In  addition  to  the  incorporation  of  more  technical  and  specialized  resources  for  enabling  semantic 
grounding51  and  augmenting  multi-disciplinary  technical  dialog,  commonly  available  resources  have 
also  been  explored  for  addressing  the  need  for  MBSE/SOSE  lexicon-support  services.  For  example, 
globally  accessible,  openly  reviewed,  and  collaboratively-edited  encyclopedic  resources  (e.g. 
Wikipedia)  are  being  evaluated  and  assessed  for  enhancing  and  augmenting  technical  dialog.  Thus,  as 
demonstrated  herein,  footnoted  encyclopedic  references  may  be  utilized  to  communicate  concepts  and 
topics  common  to  one  technology  domain,  but  otherwise  not  necessarily  more  generally  known. 

As  an  additional  step  towards  developing  a  MBSI  type  of  collaborative  mission-driven  link- 
management  development  capability,  the  current  FY 14  RF  LOS  link-management  effort  is  working 
closely  with  UxS  development  efforts  that  are  scheduled  to  utilize  the  RF  LOS  infrastructure  within 
their  tactical  ISR  mission-threads  (i.e.  CONOPS).  In  particular,  the  CONOPs  of  interest  include  near¬ 
realtime  content  delivery/distribution  network  (CDN)  and  "push  technology"  types  of  net-enabled 
services  (e.g.  full-motion  video  processing  and  distribution).52  Previous  micro/miniature  UxS53  related 
efforts  have  similarly  explored  CDN  UxS  CONOPS  [32-34].  Figure  15  is  a  dataflow  diagram  for  a 
planned  TW14  experiment  that  assesses  current  "as-is"  CDN  capabilities.  In  this  scenario,  a  rotorcraft 
platform  is  acting  as  a  surrogate-relay  for  beyond  line-of-sight  (BLOS)  C4ISR  UxS  platforms. 

As  an  example  of  architecture  reuse,  Figure  16  (from  [4])  highlights  the  value  of  standardized  model- 
based  EA/SOA  approaches.  Within  a  separate  context,  a  platform  independent  Multi-Intelligence 
Distribution  Architecture  (MID A)  was  developed  and  published  in  the  open  literature  [4].  Much  of  the 
platform  independent  modeling  (PIM)54  aspects  of  the  CDN  CONOP  is  captured  in  the  available  MIDA 
architecture.  Thus,  the  reuse  of  the  MIDA  modeling  results  provides  an  example  of  the  value  and 
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benefit  of  common  standardized  models  and  best  practices. 


Of  particular  value  is  the  use  of  a  number  of  interrelated  reference  models  within  the  development  of 
the  MIDA  reference  model.  For  example,  in  the  creation  of  the  MIDA  services  taxonomy,  the  Process- 
Exploit-Disseminate  (PED)  model  helps  to  reinforce  commonality  across  reference  models.  Also,  the 
incorporation  of  the  Department  of  Defense  Discovery  Metadata  Specification  (DDMS)  standard 
ensures  model-level  (i.e.  PIM)  compatibility  with  DoD/DISA  Net-Centric  Enterprise  Services  (NCES) 
and  information-exchange  standards  (e.g.  NIEM).55 


Figure  15  Content  Delivery  Network  (CDN)  Related  CONOP 
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Figure  16  MIDA  CONOP  (OV-1) 


Figure  17  (from  [4])  illustrates  how  common  terminology  and  standardized  reference  models  enable 
semantic  agreement  and  model-based  reuse.  In  this  case,  the  MIDA  services  taxonomy  (SvcV-4) 
provides  a  baseline  for  the  example  use-case  that  is  the  focus  of  the  current  RF  LOS  link-management 
effort  (i.e.  CDN  CONOP).  Figure  18  (from  [35])  illustrates  how  CDN  services  can  be  incrementally 
developed  within  an  agile  development  process.  In  this  example,  an  agile  development  process  can  be 
combined  with  standardized  widget  frameworks  (e.g.  OWF)  for  developing  reusable  UxS  widgets  (e.g. 
platform  control,  CDN,  analysis)  and  widget-based  applications  (e.g.  mobile  apps)  that  are  available 
via  a  logically  centralized  application  store  (e.g.  PEO  C4I  marketplace).56  The  reusable  architecture 
framework57,  as  developed  and  demonstrated,  supports  current  EA/SOA  frameworks  while  anticipating 
the  evolution  towards  the  Naval  Tactical  Cloud  (NTC)  afloat  and  ashore  [36].  The  results  of  this  effort 
provide  a  foundation  for  future  cloud-based  UxS  model-integration  and  development  capabilities.  Note 
that  emerging  model-based  UxS  standards  (e.g.  FACE,  UCS,  JAUS,  ACS)  are  additional  examples  of 
UxS  reference  models  that  further  complement  a  model-based  I&Q  approach  to  UxS  lifecycle  support 
and  model-level  platform-independent  interoperability  [37], 58 


55  Department  of  Defense  Discovery  Metadata  Specification  (DDMS; 
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56  OZONE  Widget  Framework  (OWF)  home  page,  last  access  7  Feb  2014  (https://www.owfgoss.org) 
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58  Future  Airborne  Capability  Environment  (FACE;  https://www.opengroup.us/face/; 
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UAS  Control  Segment  (UCS),  UCS  Architecture  home  page,  last  access  7  Feb  2014  (https://ucsarchitecture.org/) 
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In  summary,  RF  LOS  link-management  services  that  focus  on  end-user  IER  MOPs/MOEs,  need 
collaboration  capabilities  provided  by  MBSI  types  of  MBSE/SOSE  processes.  For  mission-dependent 
data-synchronization  requirements,  the  ability  to  engage  within  the  model-based  systems  design  phases 
of  the  systems  lifecycle,  enables  early  specification  and  design  changes  that  address  capability  gaps 
relative  to  mission-driven  IER  needs  and  priorities,  reinforcing  the  need  for  MBSI  types  of  processes. 
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Figure  17  CDN  Services  Taxonomy  (SvcV-4;  from  [6])  Figure  18  Example  of  A  Model  for  Reusable  UxS  Widgets 

within  EA/SOA/Cloud  Frameworks 


8.  Establishing  a  Unified  Model-Integration  Oriented  Lifecycle  Process:  Candidate  Components 

As  discussed  in  earlier  sections,  there  is  an  immediate  payoff  from  simply  adopting  a  MBSI  type  of 
approach  to  MBSE/SOSE  applications  that  are  targeted  for  EA/SOA/Cloud  frameworks.  An  additional 
benefit  is  the  incorporation  and  more  rigorous  management  of  a  growing  number  of  candidate 
components  that  help  establish  a  more  end-to-end  unified  MBSI  type  of  lifecycle  support  capability. 

A  candidate  component  that  facilitates  reuse  and  product  line  engineering  (PLE)  capabilities,  for 
example,  is  illustrated  in  Figure  19  (from  [38]).  In  this  case,  a  PLE  framework  can  potentially  be 
leveraged.  In  principle,  this  augments  the  previously  highlighted  E2C  facilities  and  interoperability 
certification  processes  (highlighted  in  figure  8).  Figure  20  (from  [39])  is  another  example  of  a  potential 
component  of  a  unified  end-to-end  MBSE/SOSE  lifecycle  process.  In  this  case,  the  Rapid  Integration 
and  Test  Environment  (RITE)  diagram  highlights  a  DoDI  5000. 0259  compatible  agile  development 
process  for  rapid  development  and  delivery  of  net-enabled  (i.e.  EA/SOA)  Warfighter  support  services. 


•  Common,  managed  set 
of  features  that  are 
developed  from  a 
common  set  of  core 
assets. 

•  Improvements  in  time 
to  market,  cost, 
productivity,  and 
quality. 


Figure  19  Example  of  Reusable  Enterprise  Services 


Figure  20  RITE  Lifecycle  Process  for  Agile  Development 


59  Interim  DoD  Instruction  5000.02,  “Operation  of  the  Defense  Acquisition  System,”  25  Nov  2013 
(http://www.dtic.mil/whs/directives/corres/pdf/500002_interim.pdf) 


There  are  a  number  of  other  examples  of  potential  components.  Such  examples  include  DoD/DON, 
SPAWAR,  PEO-C4I,  PMW/POR,  SSCPAC,  and  academically  developed  (e.g.  NPS)  methods, 
frameworks,  resources,  and  tools.  In  principle,  the  following  are  other  example  capabilities  that  can  be 
brought  together  and  integrated  within  an  overarching  collaborative  lifecycle  support  process:  (i) 
System  Maturity  Models  (SMM)  (e.g.  Littoral  Combat  Ship  SMM  process  [40]);  (ii)  DoD/DISAM&S 
tools  (e.g.  GOTS  Joint  Communications  Simulation  System  [41]);  (iii)  NPS  M&S  Virtual  Environment 
open-source  tools  and  resources  (e.g.  AUV  Workbench  [42-43]).  Due  to  the  breadth  and  depth  of 
MBSE/SOSE  activities  across  DoD/DISA/OSD,  intelligence  community  (IC),  and  coalition  partners, 
the  list  of  candidate  components  can  quickly  expand  to  include  a  broad  array  of  resources. 

The  above  listed  resources  are  a  sampling  of  resources  that  can  be  adapted  and  tailored  towards  a 
common  "collaboration  sandbox"  capability.  This  early  collaboration  facilitates  model  integration  and 
co-design  between  EA/SOA/Cloud  services.  Furthermore,  this  type  of  unified  lifecycle  support  process 
can  potentially  provide  a  common  basis  for  a  more  cohesive  workforce  development  and  training 
process  that  also  addresses  variance  reduction  needs  within  challenging  budgetary  climates. 

9.  Establishing  a  Unified  Framework  for  Model-Level  Integration:  Candidate  Technologies 

Maturing  technologies,  along  with  new  and  emerging  technology  developments,  are  anticipated  for 
further  addressing  more  comprehensive  model-level  integration  and  interoperability  needs.  For 
example,  a  number  of  MBSE/SOSE  developments  are  occurring  within  the  technology  domains  of 
autonomic  computing,  cyber-physical  systems,  neuromorphic  engineering,  cognitive  architecture,  agent 
architecture  (e.g.  software  agent,  mobile  agent,  autonomous  agent,  intelligent  agent)  and  multi-agent 
system  (MAS)  technology  domains.60  Model-level  integration  of  agent-based  reference-models  with 
software-defined  radio  (SDR)  reference-models  (e.g.  SCA),  is  also  of  interest  due  to  recent  availability 
of  SCA  compliant  reference  implementations  (e.g.  REDHAWK).61 

For  MBSI  related  lifecycle-support  technologies,  software  product  line  (SPL),  product  family 
engineering,  and  MAS  product-line  related  methods  (e.g.  agent-oriented  software  engineering)  are 
considered  high-payoff  emerging  capabilities  that  need  to  be  further  considered.62  The  near-term  goal  is 
to  evaluate  reference  models  (e.g.  ASRM)  and  frameworks  (e.g.  JADE)  for  incorporation  into  an  MBSI 
type  of  approach  that  is  currently  being  explored  as  a  new  proposal  effort.63  The  longer-term  goal  is  to 
potentially  establish  best-practices  for  the  integration  of  agent-based  reference  models  and  standards. 
The  intent  is  to  address  the  need  for  standardized  model-based  distributed  control64  solutions  (e.g. 
hierarchical  control,  supervisory  control,  SCAD  A,  intelligent  control). 

60  Autonomic  computing  (http://en.wikipedia.org/wiki/Autonomic_computing) 

Cyber-physical  system  (CPS;  http://en.wikipedia.org/wiki/Cyber-physical_system) 

Neuromorphic  engineering  (http://en.wikipedia.org/wiki/Neuromorphic_engineering) 

Cognitive  architecture  (http ://en. wikipedia.org/wiki/Cognitive_architecture) 

Agent  architecture  (http://en.wikipedia.org/wiki/Agent_architecture) 

Multi-agent  system  (http://en.wikipedia.org/wiki/Multi-agent_system) 

61  Software-defined  radio  (SDR;  http://en.wikipedia.org/wiki/Software-defined_radio) 

Software  Communications  Architecture  (SCA;  http://en.wikipedia.org/wiki/Software_Communications_Architecture) 
REDHAWK  home  page,  last  access  Feb  2014  (http://redhawksdr.github.io/Documentation/) 

62  Software  product  line  (http://en.wikipedia.org/wiki/Software_product_line) 

Product  family  engineering  (http://en.wikipedia.org/wiki/Product_family_engineering) 

Multiagent  systems  product  lines  (http://en.wikipedia.org/wiki/Multiagent_systems_product_lines) 

63  Agent  systems  reference  model  (http://en.wikipedia.org/wiki/Agent_systems_reference_model) 

Java  Agent  Development  Framework  (JADE;  http://en.wikipedia.org/wiki/Java_Agent_Development_Framework) 

64  Distributed  control  system  (http://en.wikipedia.org/wiki/Distributed_control_system) 


10.  Summary  and  Conclusion 


In  summary,  C2  agility  requires  timely  and  robust  net-enabled  information-sharing  services.  As 
discussed  and  reviewed,  MBSE/SOSE  and  EA/SOA/Cloud  lifecycle-support  processes  provide  a  basis 
for  a  collaborative  model-integration  oriented  approach  that  addresses  the  need  to  collaboratively 
define,  assess,  and  validate  mission-task  driven  IER  MOPs/MOEs.  This  type  of  collaborative  model- 
based  engineering  process  enables  the  growing  and  rapidly  evolving  complexities  of  MBSE/SOSE  and 
EA/SOA/Cloud  technologies  to  be  more  readily  addressed.  This  includes  improvements  in  alignment, 
reuse,  and  integration  of  multiplicities  of  reference  models  and  standards  that  need  to  be  applied  and 
tailored  to  NCW/ID  Warfighting  domains.  For  RF  LOS  communications  and  ad-hoc  networking,  this 
type  of  approach  is  a  critical  enabler  for  the  requirements  engineering  and  systems  design  aspects  of 
effective  link-management  services  that  provide  robust  and  gracefully  degrading  workflow  support. 

For  the  way-ahead,  a  number  of  additional  emerging  MBSE/SOSE  related  capabilities  were  reviewed 
for  potential  incorporation  within  a  unified  model-integration  oriented  lifecycle  support  process.  This 
further  illustrates  how  a  more  cohesive  overarching  set  of  resources  can  establish  a  basis  for  innovative, 
responsive,  and  agile  MBSE/SOSE  workforce  improvement  possibilities. 
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MBSE/SOSE:  Challenges 

Transformation  from  Systems  to  Services  (continued) 
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MBSE/SOSE:  Example  Need  and  Use-Case 

Link-Management  (continued) 
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MBSE/SOSE:  Example  Need  and  Use-Case 

Link-Management  (continued) 


SPAWN* 

_ • 

▼ 

Systems  Center 
PACIFIC 
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Conclusions  and  Future  Work: 
Agile/Incremental  MBSE/SOSE  Example 
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